Why I'm doing:

Currently, when optimizer rules encounter bugs, users often see cryptic error messages like Error 1064 (HY000): only found column statistics: {353: sum, 3} without knowing which specific rule caused the problem. This makes troubleshooting extremely difficult in production environments, as users cannot identify the problematic rule to apply workarounds.

When optimizer rules fail, especially during complex query optimization phases, the error messages lack context about which transformation or validation rule triggered the failure. This creates significant challenges for both users and developers in diagnosing and resolving optimizer-related issues.

What I'm doing:

This PR introduces a new session variable enable_optimizer_rule_debug to provide detailed debugging information when optimizer rules fail. The enhancement includes:

New Session Variable: enable_optimizer_rule_debug

• When enabled, provides detailed error context including the specific rule that caused the failure
• Shows before/after query plans when rule validation fails
• Helps identify problematic optimizer rules for troubleshooting
• Works in conjunction with the cbo_disabled_rules feature from PR #64269 to provide users with immediate workarounds

Usage Example:

-- Enable optimizer rule debugging
SET enable_optimizer_rule_debug = true;

--Rerun the failed query. When a rule fails, you'll see detailed output like:

Optimizer rule debug: Plan validation failed after applying rule [TF_PUSHDOWN_AGG_GROUPING_SET].
Validation error: Invalid plan:
LOGICAL_REPEAT
->  LogicalCTEConsumeOperator{cteId='1', limit=-1, predicate=null}
Input dependency cols check failed. 
The required cols {4} cannot obtain from input cols {13,14,15}.
Hint: This error was caught by enable_optimizer_rule_debug=true
Before:xxx
After:xxx

-- Combined with cbo_disabled_rules for workarounds:

SET cbo_disabled_rules = 'TF_PUSHDOWN_AGG_GROUPING_SET';  -- Disable the problematic rule

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.0
  • 3.5
  • 3.4
  • 3.3